Skip to content

Pre-migration fix for SNPRC specimen StorageColumnName mismatches#935

Open
labkey-martyp wants to merge 6 commits into
release26.3-SNAPSHOTfrom
26.3_fb_snprc_pg_data_migration_fixes
Open

Pre-migration fix for SNPRC specimen StorageColumnName mismatches#935
labkey-martyp wants to merge 6 commits into
release26.3-SNAPSHOTfrom
26.3_fb_snprc_pg_data_migration_fixes

Conversation

@labkey-martyp
Copy link
Copy Markdown
Contributor

@labkey-martyp labkey-martyp commented May 14, 2026

Rationale

The SNPRC SQL Server source has PropertyDescriptor rows in the specimen
storage schema whose StorageColumnName does not match any column on the
provisioned table. Left as-is, this prevents the SQL Server -> Postgres
migration from successfully reading/writing the specimen schema. The fix
runs as a SQL Server-only upgrade (26.000 -> 26.001) so the source is
clean before the migration is performed.

Related Pull Requests

Changes

  • Add SNPRC_EHRUpgradeCode.fixSpecimenStorageColumnNames: for each PropertyDescriptor in the specimen storage schema, if its StorageColumnName doesn't resolve on the provisioned table but Name does, update StorageColumnName to Name. Skips and logs when neither name resolves or both already match.
  • Bump snprc_ehr schema version 26.000 -> 26.001 and register the upgrade code.
  • Add SQL Server-only upgrade script snprc_ehr-26.000-26.001.sql invoking the Java upgrade code (no Postgres script -- runs only on the source side prior to migration).
  • Add platform:study apiJar dependency required by SNPRC_EHRUpgradeCode for SpecimenTablesProvider.

labkey-martyp and others added 3 commits May 14, 2026 16:19
Bumps schema version to 26.001 and registers SNPRC_EHRUpgradeCode, which
verifies each PropertyDescriptor in the specimen storage schema points at
an actual provisioned column and resets StorageColumnName to Name when it
doesn't.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Completes the 26.000 -> 26.001 schema bump by hooking the upgrade SQL to
the Java method added in 4c576ca.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Needed by SNPRC_EHRUpgradeCode for SpecimenTablesProvider.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@labkey-adam
Copy link
Copy Markdown
Contributor

Are you sure this issue affects SNPRC only? They're the only distribution that will receive this fix.

labkey-martyp and others added 2 commits May 18, 2026 15:57
The existing resolution check used TableInfo.getColumn() which is case-insensitive (CaseInsensitiveHashMap), so a StorageColumnName that differed from the physical column only in case was treated as already correct on the SQL Server source. After migration to a case-sensitive destination database those rows would still fail, defeating the purpose of the pre-migration fix.

Resolve the column by StorageColumnName first; consider it correct only when row.storageColumnName().equals(byStorage.getMetaDataIdentifier().getId()). Otherwise rewrite to the physical metadata identifier of either the StorageColumnName-resolved column or, failing that, the column resolved by Name. This catches both entirely-broken StorageColumnName values and case-only mismatches.

Also call OntologyManager.clearCaches() after committing the updates so any PropertyDescriptors populated into PROP_DESCRIPTOR_CACHE earlier in startup don't retain pre-update StorageColumnName values.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Copy link
Copy Markdown
Contributor Author

@labkey-martyp labkey-martyp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can follow up if we need to apply this fix more broadly. Running it multiple times is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants